WFS 2.5D point source - #117
Conversation
Thanks! |
|
I made a new push including a master rebase, so this version is up to date with latest dev. I also introduced a normalising gain in both the examples (which is open for all other examples as well) to make more clear that legacy is not amplitude correct at ref point, but the new one is. |
I'm not sure how to handle the docstring docu then. |
|
I like the name |
|
You should define the "legacy" function after the new function. |
|
IMO it's not about having internet connection or not.
It's about the inconsistency providing information of the underlying
equation (either as ASCII or LaTex math) within the docstring as useful
raw data to be rendered somewhere else, but not doing the same principle
for the referencing part. The bibtex entry tag alone does not hold
this information, I hope we agree on this.
The bibtex entry works fine and it is kind of failsafe within our environment,
but if you would ask for following same principles, I'd expect something like
providing the DOI, or the bibtex code or plain ASCII within the docstring
and a rendering stage within sphinx. I could imagine that parsing a DOI
out of docstring and grabbing all information for creating a reference list
is something people ask for or even have done. Just an idea for future work.
The current framework is very good, but we should always try to improve.
… On 15. Mar 2019, at 7:10 PM, Matthias Geier ***@***.***> wrote:
@mgeier commented on this pull request.
In sfs/mono/wfs.py:
> @@ -185,6 +191,16 @@ def point_25d(omega, x0, n0, xs, xref=[0, 0, 0], c=None, omalias=None):
Notes
-----
+ `point_25d_legacy` originates from deriving 2.5D WFS from the 2D
+ Neumann-Rayleigh integral (i.e. the approach by Rabenstein & Spors), cf.
+ Spors, S.; Rabenstein, R.; Ahrens, J. (2008): The theory of Wave Field
+ Synthesis revisited. In: Proc. of 124th Audio Eng. Soc. Convention,
+ Amsterdam, #7358.
+ Also cf. Eq. (2.145)-(2.147) in https://doi.org/10.18453/rosdok_id00001765
It's true that in the case where you have previously installed the SFS Toolbox with pip and you don't have an internet connection, you will not be able to access the references.bib file (because it's not part of the wheel package).
But the DOI doesn't help either, because you don't have an internet connection, remember?
If you do have an internet connection, you should really just go to https://sfs-python.readthedocs.io/ and look at the documentation.
And if you know that you'll be offline at some point, you can get the PDF docs, which also include the references.
Or you can build the HTML docs locally.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
Indeed. We could, instead of using BibTeX, manually add plain Sphinx citations (https://www.sphinx-doc.org/en/master/usage/restructuredtext/basics.html#citations) to the docstrings. Then your concern would be satisfied. I just don't think it's worth it.
We do.
I don't know if anyone has asked for it, but I'm quite sure nobody has implemented it.
Sure, there is room for improvement in the current situation. |
-old handling was Spors/Rabenstein, 2D to 2.5D -new one is Delft, 3D to 2.5D
Good job on that. I will remind myself from time to time to have a look on this issue. Can be closed for the moment. |
|
thx for your support!! |
3 participants
I remember we had this discussion a while ago in the Matlab toolbox. I try it here again :-)
I'd vote to change our default WFS 2.5D point source to that driving function originating from Delft, which is compatible with the recent works of Firtha, i.e. the unified WFS framework.
Our currently used version is -- due to the further approximation -- not easy to handle in terms of
The PR is merge prepared in terms of our latest changes w.r.t. driving function and docstring example handling, but not for literature references.
I would not mind to supply both driving functions with a consistent and proper name scheme. I did not come up with a meaningful idea, though.